Systems and methods for communicating with devices as Web Services

ABSTRACT

Embodiments of the present invention relate to systems and methods for communicating with smart telemetry devices as Web Services. Communication between a software application and a smart telemetry is facilitated by a server. The server accepts a request from the application, forwards the request to the smart telemetry devices, receives information from the smart telemetry device, and returns the information to the software application. The server communicates with the software application via a Web Service technology. The server communicates with the smart telemetry device either via a Web Service technology or via a protocol native to the smart telemetry device. In an exemplary embodiment of the invention, a gas or liquid tank is monitored by a system that includes a software application, a smart telemetry device, a device providing user alerts, and a server.

CROSS-REFERENCE TO RELATED APPLICATION

[0001] This application claims the benefit of U.S. Provisional PatentApplications Serial No. 60/428,903 filed Nov. 26, 2002, Serial No.60/428,904 filed Nov. 26, 2002, and Serial No. 60/428,905 filed Nov. 26,2002 which are herein incorporated by reference in their entirety.

BACKGROUND OF THE INVENTION

[0002] 1. Field of the Invention

[0003] Embodiments of the present invention relate to communicating withdevices as Web Services. More particularly, embodiments of the presentinvention relate to systems and methods for communicating with telemetrydevices so that those devices can be accessed and controlled as WebServices.

[0004] 2. Background Information

[0005] I. Telemetry Devices

[0006] Telemetry is defined by The American Heritage® Dictionary as “thescience and technology of automatic measurement and transmission of databy wire, radio, or other means from remote sources . . . to receivingstations for recording and analysis.” Smart telemetry devices aredevices that automatically measure and transmit data via a network. Theytypically consist of a controller device and a monitor device. Themonitor device is typically a sensor and conveys a measurement to thecontroller device. The controller device receives or reads themeasurement of the monitor device, and it transmits that data via anetwork protocol.

[0007] In the past, smart telemetry devices have used custom dataformats and transmission protocols to transmit data. The use of suchformats and protocols made it very difficult for the telemetry data tobe integrated into software applications. Each software applicationrequired modification to accept each new type of telemetry data. Thisresulted in costly custom software integration and often discouragedbusinesses from integrating telemetry data with their softwareapplications.

[0008] II. Software Integration of Telemetry Devices

[0009] A number of different methods have been used to integrate smarttelemetry devices into enterprise systems. These methods include customintegration, API-based middleware, and component-based middleware.

[0010] A. Custom Integration

[0011] The custom integration solution has been the most common means ofintegrating telemetry devices. FIG. 1 is a diagram showing a knowntightly-coupled custom integration method for integrating telemetrydevices with an application. This solution involves writing customsoftware that interfaces directly with device 10 and directly withapplication 11. This custom software, 12, usually contains two maincomponents: device driver 13 and application interface 14.

[0012] The developer that writes device driver 13 often has to befamiliar with the low level inner workings of the operating system. Thisis a technically difficult task that only a small number of softwareengineers are capable of doing. In addition, the developer has to readthrough reference manuals to learn how a device 10 functions tointerface with it. This type of development effort is often much moredifficult and costly than typical application development.

[0013] In addition to providing customized solutions for specificoperating systems, often the solutions must be designed for specificversions of those operating systems. For example, device drivers writtenfor WINDOW 98™ are not compatible with WINDOWS 2000™ or WINDOWS XP™.

[0014] Application interface 14 requires a developer to either integratesoftware directly into the application or to learn an applicationspecific programming interface (API). Direct integration is typicallyonly possible if the developer has access to the source code for theapplication. For larger and third party applications, the most likelysolution is to use an API. Learning an API, however, can be a timeconsuming and expensive process.

[0015] B. API-Based Middleware

[0016] A number of API-based Middleware products were introduced overthe years to try and solve the device integration problem. FIG. 2 is adiagram showing a typical API-based middleware method for integratingtelemetry devices with an application. This method involves a gateway orportal system that is running middleware software 20. Software deviceconnectors 21 are then the bridge between middleware software 20 andeach device 22. A software device connector 21 is integrated in one oftwo ways. First, it is integrated into the device itself so that thedevice may communicate with the middleware. This limits the middlewareto newly developed devices only. Second, it is integrated external tothe device, either as a plug-in for the middleware or as a separateappliance. In this case, the middleware vendor has to supply a SoftwareDevelopment Kit (SDK) for each platform and language being used by thedevice developers.

[0017] In regard to application 23, this method allows applicationdevelopers to use a single API interface to communicate with a any classof devices for which a software device connector 21 has been written.This means that the application developer can develop independently fromthe device manufacturer. Also, the API interface does not have to bemodified every time there is a new device. This was a major advance overthe custom integration solution.

[0018] However, a software application integration connector, 24, isstill required to bridge the gap between the middleware and theapplication APIs. Furthermore, application integration connector 24 isstill specific to the middleware and the middleware manufacturer has tosupply language and platform specific libraries to the developers inorder to create the connector. Library versioning problems make this avery difficult software system to maintain in a reliable fashion.

[0019] C. Component-Based Middleware

[0020] The component-based middleware method involves the use ofcomponent technologies such as COM™/DCOM™, CORBA™ and JAVA BEANS™. FIG.3 is a diagram showing a typical component-based middleware method forintegrating telemetry devices with an application. The basic idea is tocreate a standard software interface for a class of devices. Then eachdevice 30 has its own “component” middleware 31 that implementsinterface for that specific device 30. A software connector 32 is stillneeded to bridge the gap between application 33 and component middleware31.

[0021] One example of component-based middleware is OLE for ProcessControl (OPC). OPC defines a set of component interfaces used in theprocess control industry based on the Microsoft COM™ componenttechnology. Each device manufacturer then creates an OPC component foreach model of device. Application developers and integrators thendevelop their software to use a common interface that is independent ofdevice vendor.

[0022] Component-based middleware is a significant improvement overAPI-based middleware. It allows application and integration developersto work independently from middleware and device vendors. By having acomponent interface standard such as OPC, application developers candevelop support for devices into their application without having toworry about support from a middleware vendor. In addition, componenttechnologies such as CORBA™ and COM™ are somewhat language independent.They also address interface versioning issues so that componentinterfaces can evolve in a controlled manner.

[0023] However, the downside is that components are typically platformand architecture dependent. For example, a COM™ component designed for aWINDOWS NT™ system cannot be used with a Unix system. Also, thecomponent-based middleware solution requires device manufacturers tomake investments in developing software components. Device manufacturersare typically hardware-based companies that do not have in-housesoftware expertise. Therefore, the notion of supporting multiplecomponent technologies for multiple platforms is a daunting task fordevice manufacturers. And often it is not undertaken with much success.

[0024] In view of the foregoing, it can be appreciated that asubstantial need exists for systems and methods that can advantageouslyprovide for the integration of smart telemetry devices with applicationsof an enterprise system.

BRIEF SUMMARY OF THE INVENTION

[0025] Embodiments of the present invention relate to systems andmethods for communicating with smart telemetry devices within anenterprise system. In a preferred embodiment the communication betweenthe smart devices and the enterprise system is via Web Services.

[0026] One basic embodiment of such a system includes a softwareapplication, a smart telemetry device, and a server. The smart telemetrydevice includes a controller device and a monitor device. The serveraccepts a request from the software application for discovering,configuring, or controlling the smart telemetry device via a Web Servicetechnology. This technology includes but is not limited to XML, SOAP,WSDL, UDDI, HTTP, and SMTP. The server then forwards the request to thesmart telemetry device via a protocol native to the telemetry device.Information sent from the smart telemetry device in response to therequest is passed to the server via the protocol native to the telemetrydevice. Finally, the server returns the information to the applicationvia the same Web Service technology of the original request.

[0027] In another embodiment, the communication between the server andthe smart telemetry device is also via a Web Service technology. Theserver forwards the request from the application to the smart telemetrydevice via a Web Service technology. Likewise, the information sent fromthe smart telemetry device in response to the request is passed to theserver via the same Web Service technology.

[0028] In either embodiment, the server functions can be organized intothree separate categories. These are Web Services accessible to thesoftware application that provide communication and managementinterfaces for the smart telemetry device, an infrastructure allowingfor the smart telemetry device to exchange services with the server, andcore Web Services that provide functionality to both the softwareapplication and the smart telemetry device.

[0029] The Web Services accessible to the software application thatprovide communication and management interfaces for the smart telemetrydevice include but are not limited to configuration management,directory services, messaging services, security services, and devicespecific services. The infrastructure allowing for the smart telemetrydevice to exchange services with the server includes but is not limitedto a device message service, a device message translator, a deviceextension service, and a device switchboard. The core Web Services thatprovide functionality to both the software application and the smarttelemetry device include but are not limited to configurationmanagement, universal messaging, dial-tone access management, securityservices, and device class interfaces.

[0030] An embodiment of a method used by a server to facilitate thecommunication between a software application and a smart telemetrydevice includes four steps. First, the server accepts a request from thesoftware application comprising discovering, configuring, andcontrolling the smart telemetry device via a Web Service technology.Second, the server forwards the request to the smart telemetry devicevia a protocol native to the smart telemetry device. Third, the serverreceives information from the smart telemetry device in response to therequest via the protocol native to the smart telemetry device. Fourth,the server returns the information to the software application via theWeb Service technology.

[0031] In another embodiment, the server forwards the request to thesmart telemetry device via a Web Service technology. The server thenreceives the information from the smart telemetry device in response tothe request via the same Web Service technology.

[0032] These methods involve requests initiated by the application. Arequest may also be initiated by the smart telemetry device. In oneembodiment, the server first accepts a request from the smart telemetrydevice to send information to the application via a protocol native tothe smart telemetry device. It then forwards the information to theapplication via a Web Service technology. In another embodiment, theserver first accepts a request from the smart telemetry device to sendinformation to the application via a first Web Service technology. Itthen forwards the information to the application via a second WebService technology.

[0033] In another embodiment, a method by which a server, which acts asproxy between a smart telemetry device and an application, communicateswith a smart telemetry device is provided. This method begins byreceiving a message from the smart telemetry device in a Web Servicetechnology. This technology includes XML. The identity of the smarttelemetry device is then determined from the address or device classinformation contained in the message. The server then selects a devicedescription document, which specifies how the smart telemetry devicecommunicates with the server, from the identity of the smart telemetrydevice. Finally, the server translates the body of the message using thedevice description document.

[0034] In order for a server to receive a message from a smart device ina Web Service technology, the smart device must be capable of generatingsuch a message. Another embodiment of the present invention is a systemfor a smart telemetry device to communicate with an application via anXML format. This system includes a communications link that provides thetransport for exchanging messages between the smart telemetry device andthe application. The system also includes an input message queue thatstores incoming messages and an output message queue that storesoutgoing messages. An incoming message is directed to an XML messageprocessor that parses the incoming message and forwards the payload ofthe incoming message to a firmware function. An outgoing message isgenerated by an XML message generator that converts a firmware-generatedmessage to XML. Finally, the system includes device specific functionsthat are firmware functions that make up the smart telemetry device'sfunctionality.

[0035] A specific embodiment of the present invention is a liquid andgas tank telemetry system. This system includes a tank containing aliquid, a gas, or both. The system has one or more sensors attached tothe tank to provide information about the tank. This informationincludes tank pressure, line pressure, tank level, tank temperature,tank leakage detection, and flow rate in and out of the tank. The systemincludes a telemetry device that automatically receives or reads datafrom the one or more sensors. The system has a telemetry database thatstores telemetry data. The system also includes at least on softwareapplication. Such software applications include but are not limited toinventory, scheduling and routing, billing or invoice, and enterpriseresource planning systems. The system also has a device forcommunicating telemetry alerts to a user. The device for communicatingtelemetry alerts to a user include but at not limited to a computer,PDA, cellular phone, telephone, and pager. Finally, the system iscontrolled by a telemetry server that communicates with the telemetrydevice, retrieves and stores data in the telemetry database, provides aninterface to the software application, and forwards telemetry alerts toa means for communication telemetry alerts to a user.

BRIEF DESCRIPTION OF THE DRAWINGS

[0036]FIG. 1 is a diagram showing a known tightly-coupled customintegration method for integrating telemetry devices with anapplication.

[0037]FIG. 2 is a diagram showing a typical API-based middleware methodfor integrating telemetry devices with an application.

[0038]FIG. 3 is a diagram showing a typical component-based middlewaremethod for integrating telemetry devices with an application.

[0039]FIG. 4 is a schematic diagram showing an exemplary system forcommunicating with smart telemetry devices as Web Services in accordancewith an embodiment of the present invention.

[0040]FIG. 5 is a flowchart showing an exemplary method used by a serverto proxy communications between a software application and a smarttelemetry device where the request is initiated by the application andthe communication to and from the smart telemetry device is via aprotocol native to the smart telemetry device in accordance with anembodiment of the present invention.

[0041]FIG. 6 is a flowchart showing an exemplary method used by a serverto proxy communications between a software application and a smarttelemetry device where the request is initiated by the application andthe communication to and from the smart telemetry device is via a WebService technology in accordance with an embodiment of the presentinvention.

[0042]FIG. 7 is a flowchart showing an exemplary method used by a serverto proxy communications between a software application and a smarttelemetry device where the request is initiated by the smart telemetrydevice and the communication to and from the smart telemetry device isvia a protocol native to the smart telemetry device in accordance withan embodiment of the present invention.

[0043]FIG. 8 is a flowchart showing an exemplary method used by a serverto proxy communications between a software application and a smarttelemetry device where the request is initiated by the smart telemetrydevice and the communication to and from the smart telemetry device isvia a Web Service technology in accordance with an embodiment of thepresent invention.

[0044]FIG. 9 is a schematic diagram showing the three separatecategories of server functions provided by a server that proxiescommunication between a smart telemetry device and an application inaccordance with an embodiment of the present invention.

[0045]FIG. 10 is a schematic diagram showing the server functions thatallow software applications to manage and access telemetry data inaccordance with an embodiment of the present invention.

[0046]FIG. 11 is a schematic diagram showing the server functions thatmake up the infrastructure allowing for the smart telemetry device toexchange services with the server in accordance with an embodiment ofthe present invention.

[0047]FIG. 12 is a schematic diagram showing the server functions thatmake up core Web Services that provide functionality to both thesoftware application and the smart telemetry device in accordance withan embodiment of the present invention.

[0048]FIG. 13 is a flowchart showing an exemplary method used by aserver to translate messages from a smart telemetry device in accordancewith an embodiment of the present invention.

[0049]FIG. 14 is a schematic diagram showing an exemplary systemallowing a smart telemetry device to communicate with a softwareapplication via an XML format in accordance with an embodiment of thepresent invention.

[0050]FIG. 15 is a schematic diagram showing an exemplary liquid and gastank telemetry system in accordance with an embodiment of the presentinvention.

DETAILED DESCRIPTION OF THE INVENTION

[0051]FIG. 4 is a schematic diagram showing an exemplary system forcommunicating with smart telemetry devices as Web Services in accordancewith an embodiment of the present invention. System 400 includessoftware application 40, at least one smart telemetry device, 41, andUniversal Telemetry System (UTS) server 42. Server 42 accepts a requestfrom software application 40 for discovering, configuring, orcontrolling smart telemetry device 41 via a Web Service technology at43. Server 42 forwards the request to smart telemetry device 41 via aprotocol native to smart telemetry device 41 at 44. Server 42 receivesinformation from smart telemetry device 41 in response to the requestvia a protocol native to smart telemetry device 41 at 45. Server 42returns the information to the software application via the Web Servicetechnology at 46. The Web Service technology used includes but is notlimited to XML, SOAP, WSDL, UDDI, HTTP, and SMTP. Each smart telemetrydevice 41 includes controller device 412 to communicate over a networkand monitor device 414 to take measurements.

[0052] In another embodiment, smart telemetry device 41 communicateswith server 42 via a Web Service technology. In this case, server 42forwards the request to smart telemetry device 41 via a Web Servicetechnology at 44. Server 42 receives information from smart telemetrydevice 41 in response to the request via a Web Service technology at 45.The Web Service technology used to communicate between smart telemetrydevice 41 and server 42 includes but is not limited to XML, SOAP, WSDL,UDDI, HTTP, and SMTP.

[0053]FIG. 5 is a flowchart showing an exemplary method used by a serverto proxy communications between a software application and a smarttelemetry device where the request is initiated by the application andthe communication to and from the smart telemetry device is via aprotocol native to the smart telemetry device in accordance with anembodiment of the present invention.

[0054] In step 51, the server accepts a request from the softwareapplication to discover, configure, or control the smart telemetrydevice via a Web Service technology.

[0055] In step 52, the server then forwards the request to the smarttelemetry device via a protocol native to the smart telemetry device. Instep 53, information is received by the server from the smart telemetrydevice via the protocol native to the smart telemetry device.

[0056] Finally, in step 54, the server returns the information to thesoftware application via the Web Service technology.

[0057]FIG. 6 is a flowchart showing an exemplary method used by a serverto proxy communications between a software application and a smarttelemetry device where the request is initiated by the application andthe communication to and from the smart telemetry device is via a WebService technology in accordance with an embodiment of the presentinvention.

[0058] In step 61, the server accepts a request from the softwareapplication to discover, configure, or control the smart telemetrydevice via a first Web Service technology.

[0059] In step 62, the server then forwards the request to the smarttelemetry device via a second Web Service technology.

[0060] In step 63, information is received by the server from the smarttelemetry device via the second.Web Service technology.

[0061] Finally, in step 64, the server returns the information to thesoftware application via the first Web Service technology at 64.

[0062]FIG. 7 is a flowchart showing an exemplary method used by a serverto proxy communications between a software application and a smarttelemetry device where the request is initiated by the smart telemetrydevice and the communication to and from the smart telemetry device isvia a protocol native to the smart telemetry device in accordance withan embodiment of the present invention.

[0063] In step 71, the server accepts a request from the smart telemetrydevice to send information to the application via a protocol native tothe smart telemetry device.

[0064] In step 72, the server then forwards the request to theapplication via a Web Service technology.

[0065]FIG. 8 is a flowchart showing an exemplary method used by a serverto proxy communications between a software application and a smarttelemetry device where the request is initiated by the smart telemetrydevice and the communication to and from the smart telemetry device isvia a Web Service technology in accordance with an embodiment of thepresent invention.

[0066] In step 81, the server accepts a request from the smart telemetrydevice to send information to the application via a first Web Servicetechnology.

[0067] In step 82, the server then forwards the request to theapplication via a second Web Service technology.

[0068]FIG. 9 is a schematic diagram showing the three separatecategories of server functions provided by a server that proxiescommunication between a smart telemetry device and an application inaccordance with an embodiment of the present invention. UTS server 90provides a central point where smart telemetry devices 91, 92 andsoftware application 93 come together. Smart telemetry device 91 is“tightly coupled” to UTS server 90 at 94. This means that smarttelemetry device 91 communicates with UTS server 90 using a protocolnative to smart telemetry device 91. Smart telemetry device 92 is“loosely coupled” to UTS server 90 at 95. This means that smarttelemetry device 92 communicates with UTS server 90 using a Web Servicetechnology including but not limited to XML, SOAP, WSDL, UDDI, HTTP, andSMTP. Similarly, software application 93 is loosely coupled to UTSserver 90 at 96.

[0069] The first category of functions that UTS server 90 provides isTelemetry Application Services (TAS) 97. TAS 97 allow softwareapplications to manage and access telemetry data. The second category offunctions is Devices Services Exchange (DSX) 98. This component allowsUTS server 90 to provide telemetry devices with centralized services aswell as connectivity to applications. Finally the third category offunctions is core services 99. Core services 99 are at the heart of theUTS server 90. Core services 98 provide functionality for both TAS 97and DSX 98.

[0070]FIG. 10 is a schematic diagram showing the server functions thatallow software applications to manage and access telemetry data inaccordance with an embodiment of the present invention. Softwareapplication 93 communicates with UTS server 90 via TAS 97. TAS 97 areWeb Services that provide communication and management interfaces fortelemetry devices.

[0071] TAS 97 has two main service categories, common services 100 anddevice specific services 101. Common services 100 provide interfacesthat are consistent for all types of telemetry devices. While, devicespecific services 101 include interfaces that are unique to each classof device.

[0072] Through configuration management 102, TAS 97 provide applicationswith the ability to manage the configuration of devices. Applicationscan determine the current settings for a device as well as change aspecific setting on a group of devices or on a single device. Inaddition, multiple configuration “personalities” may be stored on theserver for each device. Using TAS 97, applications are able to changecommon settings on any telemetry device without the need of any devicespecific software library or component.

[0073] Directory services 103 provided by TAS 97 enable applications tolocate devices using a variety of criteria. Applications are able toquickly and easily locate devices based on serial number, model number,location, state, communication protocol or function of the device. Thesedevices may be located anywhere on the WAN that is managed by UTS server90.

[0074] Applications have the ability to manage device generatedmessaging using the messaging services 104. Messaging services allow anapplication to manage where and when messages are sent to users. Devicescan send simple messages and alerts to the UTS server 90. UTS server 90then assumes the responsibility for forwarding the messages and alertsto the appropriate users and applications. Applications can create therules needed to route messages to users

[0075] Protecting and restricting access to telemetry data are theprimary functions of security services 105. The UTS server 90 allowsadministrative applications to manage any access control and securitysettings for devices. For example, applications may be able to assignowners to devices and group devices into domains.

[0076] TAS 97 provide an infrastructure that allows telemetry devices toexpose Web Service interfaces that are specific to the device. Thesedevice specific services 101 are dynamically created based on the DeviceDescription Document (DDD) for the telemetry device. Applications 93 canuse these device specific services to access functions that are uniqueto the device.

[0077]FIG. 11 is a schematic diagram showing the server functions thatmake up the infrastructure allowing for the smart telemetry device toexchange services with the server in accordance with an embodiment ofthe present invention. DSX 98 provides an infrastructure for allowingdevices to exchange services with a central server. This exchange ofservices goes in both directions. The central server, UTS server 90, canprovide services to smart telemetry device 92 and smart telemetry device92 can provide services to UTS server 90. DSX 98 enables applications toaccess the services provided by devices. Also, DSX 98 provides amechanism that allows services to be offloaded from devices and executedwithin UTS server 90.

[0078] A DDD provides the information required by DSX 98 to support anew class of devices. Portions of the DDD are used by components of DSX98 to perform device specific functions.

[0079] Device Message Service (DMS) 111 provides a mechanism forgenerating out-bound messages that are specific to the type of device.Messages are generated by calling the DMS API. DMS 111 will then, inturn, execute device specific scripts that create messages specific forthe device.

[0080] Device Message Translator (DMT) 112 translates incoming devicemessages into server scripts. The resulting server scripts then callcore services 99 as well as DMS 111.

[0081] Device Extension Service (DES) 113 allows devices to offloadfunctionality so that it may be executed on UTS server 90. This canreduce the cost of the device while providing increased functionality.

[0082] Device Switchboard (DSB) 114 maintains a collection of devicemail boxes. Each mail box contains both in and out queues to buffermessages. The mail box then communicates with the device via acommunications link. DSB 114 is responsible for routing messages to andfrom each of the device mail boxes.

[0083]FIG. 12 is a schematic diagram showing the server functions thatmake up core Web Services that provide functionality to both thesoftware application and the smart telemetry device in accordance withan embodiment of the present invention. Core services 99 are the heartof UTS server 90. Core services 99 provide functionality that is used byboth TAS 97 and DSX 98.

[0084] Configuration Management Core Service (CMCS) 121 allows devicesto use UTS server 90 to store their configuration parameters. Parametersare stored and retrieved using an XML document format. This allows eachdevice to define its own parameters to be stored. CMCS 121 also providesthe interface that allows applications to access device configurationparameters via TAS 97.

[0085] Universal Messaging Core Service (UMCS) 122 allows devices togenerate informative messages. and alerts that can be forwarded to usersand applications via email, text messaging, etc. Devices send simplemessages to UMCS 122. UMCS 122 then forwards these messages to users andapplications based on the rules defined via TAS 97. The device does notneed to be aware of any of the details of which users and applicationsare to receive messages.

[0086] Dial-Tone Access Management (DTAM) 123 is a core service thatprovides the infrastructure that allows devices to communicate usingintermittent (or shared) connections as well as communicating behind aNetwork Address Translated (NAT) firewall. For example, some devices mayshare a common dial-up Internet connection. These devices need to beprogrammed with ISP account information and the schedule in which theycan make their connections.

[0087] Security Core Service (SCS) 124 provides a system that allowsdevices to communicate with UTS server 90 in a secure and non-repudiatedmanner. In addition, SCS 124 provides the means of authenticatingapplications and restricts each application's access to the devices. SCS124 maintains an access control list for each device. The access controllist for a device determines which applications or users are allowed toaccess it or its data. SCS 124 provides this infrastructure ofrestricting access as well as the interface that allows applications toadministrate each device's access.

[0088] Device Class Interfaces (DCI) 125 are core services that allowdevices to specify their own interface that can be used by applications.Each device is a member of a particular device class. Each device classmay implement its own interface that is described and defined atrun-time by the device class information provided by each device.Applications can use DCI 125 to access special device specific functionsthat are unique to a particular class of devices.

[0089]FIG. 13 is a flowchart showing an exemplary method used by aserver to translate messages from a smart telemetry device in accordancewith an embodiment of the present invention. A DDD is used to describehow a UTS server interfaces to specific class of device. The DDDcontains all the information needed to communicate with a given deviceas well as any specific class information (from the DCI) that is exposedto applications.

[0090] In step 131, device XML messages are received by the UTS server.These messages are routed based on address or device class informationcontained in the XML envelope.

[0091] In step 132, the identity of the device that sent the message isdetermined.

[0092] In step 133, the DDD for that device is selected.

[0093] In step 134, the message is then translated based on thespecification found in the DDD. The resulting translation should producea server script. This script is then executed to process the payload ofthe message.

[0094]FIG. 14 is a schematic diagram showing an exemplary systemallowing a smart telemetry device to communicate with a softwareapplication via an XML format in accordance with an embodiment of thepresent invention. The goal of a Universal Telemetry Access Protocol(UTAP) is to provide a flexible way for a smart telemetry device 141 tocommunicate with software application 142, while not imposing highlevels of complexity and costs on smart telemetry device 141.

[0095] Communication link 143 for smart telemetry device 141 isresponsible for implementing the UTAP transport layer. At a minimum,communication link 143 must be composed of an IP stack with either TCPor UDP support. However, most devices will want to utilize a commontransport that is firewall friendly such as HTTP or SMTP.

[0096] To insure messages are not lost due to communication failures orsmart telemetry device 141 being busy, both an input message queue, 144,and an output message queue, 145, are required. UTAP only requires thateach smart telemetry device must be capable of holding a single messagein each queue. The actual implementation of the queue is left to thedevice designer. Generally, all devices need a memory-based solution forthe input queue. However, in some devices it may be desirable to useless memory and simply be capable of re-generating the last message onthe output queue. The device itself will define the maximum message sizethat can be received. However, all UTAP devices are capable of receivingthe minimum UTAP message size.

[0097] XML message processor 146 is responsible for processing themessages received from an application. The implementation of XML messageprocessor 146 is based on a specialized XML parser. This specialized XMLparser is compact in both memory and code requirements. The parserprocesses the XML envelope of each received message and forwards thepayload of the message to the appropriate firmware function.

[0098] XML message generator 147 is responsible for packaging messagethat are to be sent to the application. Other firmware functions callthe XML message generator 147 anytime a message needs to be transmitted.When a message is to be generated, an appropriate XML envelope isprepared and the payload of the message is encoded and inserted inside.The message is then sent to software application 142 via output messagequeue 145.

[0099] Device Specific Functions 148 are what makes each type of devicedifferent. These functions are the core of the firmware that gives smarttelemetry device 141 its functionality. UTAP makes no restrictions onthis portion of the firmware.

[0100] A DDD is used to describe how an application interfaces to aspecific class of device using UTAP. The DDD contains all theinformation needed to communicate with a given device. Softwareapplication 142 references the DDD in order to perform the necessarymessage translations to and from smart telemetry device 141.

[0101]FIG. 15 is a schematic diagram showing an exemplary liquid and gastank telemetry system in accordance with an embodiment of the presentinvention. System 1500 includes a monitor device 1502, a controllerdevice 1503, liquid/gas telemetry server 1504, telemetry database 1506,liquid/gas enterprise application 1507, and device for communicatingtelemetry alerts to a user 1509. Tank 1501 contains a liquid, a gas or acombination of a liquid and a gas. At least one monitor device 1502 isattached to tank 1501 to measure the inventory in the tank and toprovide diagnostic information about the tank. One skilled in the artwill appreciate that monitor device includes a sensor. This inventoryand diagnostic information includes but is not limited to line pressure,tank pressure, tank level, tank temperature, tank leakage detection, andflow rate in and out of the tank. Controller device 1503 automaticallyreceives or reads data from one or more monitor devices, 1502. Oneskilled in the art will appreciate that controller device 1503 includesa telemetry device and the combination of controller device 1503 andmonitor device 1502 includes a smart telemetry device. Monitor device1502 may be directly connected to controller device 1503 using a serialconnection (RS232, RS485, USB, IEEE 1394, modem, etc.). It may beconnected using a network connection (Ethernet or PPP). It may also beconnected using a wireless connection (802.11, Bluetooth, 802.15, IRDA,or other proprietary wireless protocols).

[0102] Controller device 1503 communicates with a liquid/gas telemetryserver 1504 via a network (Internet, Ethernet, 802.11, etc.) at 1505.Liquid/gas telemetry server 1504 is responsible for receiving data fromcontroller devices, storing and processing the telemetry data, andproviding the raw or processed telemetry data to enterprise application.In addition, the telemetry server may provide alerts to users based onthe analysis of the telemetry data. Telemetry database 1506 is used tostore and organize the raw and processed telemetry data. Raw data refersto data that has been directly taken from controller device 1503 and hasnot been interpreted, manipulated or transformed. Processed data refersto data that has been translated, interpreted, manipulated, transformedor reduced. Telemetry database 1506 includes an SQL rational database.

[0103] Software application 1507 is any application used by a Liquid/Gasdistribution, manufacturing or processing business. An exemplaryapplication includes inventory systems, scheduling and routing,billing/invoice systems and enterprise resource planning systems.Software application 1507 couples to liquid/gas telemetry server 1504 at1508, coupling 1508 can be, for example, an XML-based interface. Thisinterface may use any network transport layer that is capable ofsupporting XML payloads. Exemplary transports include HTTP, SMTP, DIME,and SIP.

[0104] Users may receive alerts from liquid/gas telemetry server 1504via device for communicating telemetry alerts to a user 1509 at 1510.Device for communicating telemetry alerts to a user 1509 includes but isnot limited to a computer, cellular phone, telephone, PDA, and pager.These alerts inform users of real-time inventory and diagnosticinformation. The alerts may be delivered as email, pager/text messaging,voice messages or instant messaging. The transport for sending useralerts may be any network transport such as HTTP, SMTP, DIME, or SIP. Inaddition, other XML based protocols such as SOAP and XML may be utilizedin conjunction with the transport layer.

[0105] As used to describe embodiments of the present invention, theterm “coupled” encompasses a direct connection, an indirect connection,or a combination thereof. Two devices that are coupled can engage indirect communications, in indirect communications, or a combinationthereof. Moreover, two devices that are coupled need not be incontinuous communication, but can be in communication typically,periodically, intermittently, sporadically, occasionally, and so on.Further, the term “communication” is not limited to directcommunication, but also includes indirect communication.

[0106] Embodiments of the present invention relate to datacommunications via one or more networks. The data communications can becarried by one or more communications channels of the one or morenetworks. A network can include wired communication links (e.g., coaxialcable, copper wires, optical fibers, a combination thereof, and so on),wireless communication links (e.g., satellite communication links,terrestrial wireless communication links, satellite-to-terrestrialcommunication links, a combination thereof, and so on), or a combinationthereof. A communications link can include one or more communicationschannels, where a communications channel carries communications. Forexample, a communications link can include multiplexed communicationschannels, such as time division multiplexing (“TDM”) channels, frequencydivision multiplexing (“FDM”) channels, code division multiplexing(“CDM”) channels, wave division multiplexing (“WDM”) channels, acombination thereof, and so on.

[0107] In accordance with an embodiment of the present invention,instructions configured to be executed by a processor to perform amethod are stored on a computer-readable medium. The computer-readablemedium can be a device that stores digital information. For example, acomputer-readable medium includes a compact disc read-only memory(CD-ROM) as is known in the art for storing software. Thecomputer-readable medium is accessed by a processor suitable forexecuting instructions configured to be executed. The terms“instructions configured to be executed” and “instructions to beexecuted” are meant to encompass any instructions that are ready to beexecuted in their present form (e.g., machine code) by a processor, orrequire further manipulation (e.g., compilation, decryption, or providedwith an access code, etc.) to be ready to be executed by a processor.

[0108] Systems and methods in accordance with an embodiment of thepresent invention disclosed herein can advantageously improve theintegration of smart telemetry devices with enterprise softwareapplications. The use of a universal telemetry system server accessedvia Web Service technology provides applications with a common interfacefor discovering and configuring devices. The use of a universaltelemetry system server accessed via Web Service technology enablessmart telemetry devices to define new Web Services dynamically. A liquidand gas telemetry system using these systems and methods provides areal-time view of the of the status of liquid and gas tanks in use. Theuse of Web Services to develop this system reduces its expense anddecreases the complexity of connecting remote device information toenterprise applications.

[0109] The foregoing disclosure of the preferred embodiments of thepresent invention has been presented for purposes of illustration anddescription. It is not intended to be exhaustive or to limit theinvention to the precise forms disclosed. Many variations andmodifications of the embodiments described herein will be apparent toone of ordinary skill in the art in light of the above disclosure. Thescope of the invention is to be defined only by the claims appendedhereto, and by their equivalents.

[0110] Further, in describing representative embodiments of the presentinvention, the specification may have presented the method and/orprocess of the present invention as a particular sequence of steps.However, to the extent that the method or process does not rely on theparticular order of steps set forth herein, the method or process shouldnot be limited to the particular sequence of steps described. As one ofordinary skill in the art would appreciate, other sequences of steps maybe possible. Therefore, the particular order of the steps set forth inthe specification should not be construed as limitations on the claims.In addition, the claims directed to the method and/or process of thepresent invention should not be limited to the performance of theirsteps in the order written, and one skilled in the art can readilyappreciate that the sequences may be varied and still remain within thespirit and scope of the present invention.

What is claimed is:
 1. A system for communicating with smart telemetry devices as Web Services, the system comprising: a software application; a smart telemetry device; and a server, wherein the server accepts a request from the software application comprising one or more of discovering, configuring, and controlling the smart telemetry device via a Web Service technology, forwards the request to the smart telemetry device via a protocol native to the smart telemetry device, receives information from the smart telemetry device in response to the request via the protocol native to the smart telemetry device, and returns the information to the software application via the Web Service technology.
 2. The system of claim 1, wherein the Web Service technology comprises one or more of XML, SOAP, WSDL, UDDI, HTTP, and SMTP.
 3. The system of claim 1, wherein the smart telemetry device comprises one or more of a controller device and a monitor device.
 4. A method used by a server to proxy the communication between a software application and a smart telemetry device, the method comprising: accepting a request from the software application comprising discovering, configuring, and controlling the smart telemetry device via a Web Service technology; forwarding the request to the smart telemetry device via a protocol native to the smart telemetry device; receiving information from the smart telemetry device in response to the request via the protocol native to the smart telemetry device; and returning the information to the software application via the Web Service technology.
 5. The method of claim 4, wherein the Web Service technology comprises one or more of XML, SOAP, WSDL, UDDI, HTTP, and SMTP.
 6. The system of claim 4, wherein the smart telemetry device comprises one or more of a controller device and a monitor device.
 7. A system for communicating with smart telemetry devices as Web Services, the system comprising: a software application; a smart telemetry device; and a server, wherein the server accepts a request from the software application comprising discovering, configuring, and controlling the smart telemetry device via a first Web Service technology, forwards the request to the smart telemetry device via a second Web Service technology, receives information from the smart telemetry device in response to the request via the second Web Service technology, and returns the information to the software application via the first Web Service technology.
 8. The system of claim 7, wherein the first Web Service technology comprises one or more of XML, SOAP, WSDL, UDDI, HTTP, and SMTP.
 9. The system of claim 7, wherein the second Web Service technology comprises one or more of XML, SOAP, WSDL, UDDI, HTTP, and SMTP.
 10. The system of claim 7, wherein the smart telemetry device comprises one or more of a controller device and a monitor device.
 11. The system of claim 7, wherein the server provides Web Services accessible to the software application that provide communication and management interfaces for the smart telemetry device, an infrastructure allowing for the smart telemetry device to exchange services with the server, and core Web Services that provide functionality to both the software application and the smart telemetry device.
 12. The system of claim 11, wherein the Web Services accessible to the software application that provide communication and management interfaces for the smart telemetry device comprise configuration management that allows the application to determine the current settings for the smart telemetry device and to change a specific setting on the smart telemetry device.
 13. The system of claim 11, wherein the Web Services accessible to the software application that provide communication and management interfaces for the smart telemetry device comprise a directory service that enables the application to locate the smart telemetry device based on one or more of serial number, model number, location, state, communication protocol, and function of the smart telemetry device.
 14. The system of claim 11, wherein the Web Services accessible to the software application that provide communication and management interfaces for the smart telemetry device comprise a messaging service that allows the application to manage the messages and alerts that the smart telemetry device can send.
 15. The system of claim 11, wherein the Web Services accessible to the software application that provide communication and management interfaces for the smart telemetry device comprise a security service that allows the application to manage the access control and security settings for the smart telemetry device.
 16. The system of claim 11, wherein the Web Services accessible to the software application that provide communication and management interfaces for the smart telemetry device comprise a device specific service that allows the application to access functions that are specific to the smart telemetry device.
 17. The system of claim 11, wherein the infrastructure allowing for the smart telemetry device to exchange services with the server comprises a device message service that provides a mechanism for generating out-bound messages that are specific to the smart telemetry device.
 18. The system of claim 11, wherein the infrastructure allowing for the smart telemetry device to exchange services with the server comprises a device message translator that translates incoming messages from the smart telemetry device into server scripts.
 19. The system of claim 11, wherein the infrastructure allowing for the smart telemetry device to exchange services with the server comprises a device extension service that allows the smart telemetry device to offload functionality so that it may be executed on the server.
 20. The system of claim 11, wherein the infrastructure allowing for the smart telemetry device to exchange services with the server comprises a device switchboard that is responsible for routing in and out message queues of the smart telemetry device.
 21. The system of claim 11, wherein the core Web Services that provide functionality to both the software application and the smart telemetry device comprise a core configuration management service that allows the smart telemetry device to store its configuration parameters on the server.
 22. The system of claim 11, wherein the core Web Services that provide functionality to both the software application and the smart telemetry device comprise a universal message service that allows the smart telemetry device to store its message on the server.
 23. The system of claim 11, wherein the core Web Services that provide functionality to both the software application and the smart telemetry device comprise a dial-tone access management service that allows the smart telemetry device to communicate with the application using intermittent or shared connections.
 24. The system of claim 11, wherein the core Web Services that provide functionality to both the software application and the smart telemetry device comprise a security core service that allows the smart telemetry device to communicate in a secure and non-repudiated manner.
 25. The system of claim 11, wherein the core Web Services that provide functionality to both the software application and the smart telemetry device comprise a device class interface service that allows the smart telemetry device to specify the interface that that the application can use to access the smart telemetry device.
 26. A method used by a server to proxy communication between a software application and a smart telemetry device, the method comprising: accepting a request from the software application comprising discovering, configuring, and controlling the smart telemetry device via a first Web Service technology; forwarding the request to the smart telemetry device via a second Web Service technology; receiving information from the smart telemetry device in response to the request via the second Web Service technology; and returning the information to the software application via the first Web Service technology.
 27. The method of claim 26, wherein the first Web Service technology comprises one or more of XML, SOAP, WSDL, UDDI, HTTP, and SMTP.
 28. The method of claim 26, wherein the second Web Service technology comprises one or more of XML, SOAP, WSDL, UDDI, HTTP, and SMTP.
 29. The system of claim 26, wherein the smart telemetry device comprises one or more of a controller device and a monitor device.
 30. A method used by a server, which acts as a proxy between a smart telemetry device and an application, to communicate with the smart telemetry device, the method comprising: receiving an message from the smart telemetry device in a Web Service technology; determining the identity of the smart telemetry device based on one or more of address and device class information contained in the message; selecting a device description document that specifies how the smart telemetry device communicates with the server from the identity of the smart telemetry device; and using the device description document to translate the body of the message.
 31. The method of claim 30, wherein the Web Service technology comprises XML.
 32. A system for a smart telemetry device to communicate with an application via an XML format, the system comprising: a communications link that provides the transport for exchanging messages between the smart telemetry device and the application; an input message queue that stores incoming messages; an output message queue that stores outgoing messages; an XML message processor that parses the incoming message and forwards the payload of the incoming message to a firmware function; an XML message generator that converts a firmware-generated message to XML; and device specific functions that are firmware functions that make up the smart telemetry device's functionality.
 33. A liquid and gas tank telemetry system, the system comprising: a tank containing material comprising one or more of a liquid and a gas; a monitor device that is attached to the tank to provide information about the tank; a controller device that automatically receives or reads data from the monitor device; a telemetry database that stores telemetry data; a software application; a device for communicating telemetry alerts to a user; and a telemetry server that communicates with the controller device, retrieves and stores data in the telemetry database, provides an interface to the software application, and forwards telemetry alerts to a means for communication telemetry alerts to a user.
 34. The system of claim 33, wherein the monitor device that is attached to the tank to provide information about the tank comprises one or more sensors that measure one or more of tank pressure, line pressure, tank level, tank temperature, tank leakage detection, and flow rate in and out of the tank.
 35. The system of claim 33, wherein the software application comprises one or more of inventory, scheduling and routing, billing or invoice, and enterprise resource planning systems.
 36. The system of claim 33, wherein the device for communication telemetry alerts to a user comprises one or more of a computer receiving email, a PDA receiving email, a cellular phone receiving email, a PDA receiving text messaging, a cellular phone receiving text messaging, a pager receiving text messaging, a cellular phone receiving voice messaging, a telephone receiving voice messaging, a PDA receiving instant messaging, a cellular phone receiving instant messaging, and a computer receiving instant messaging.
 37. A method used by a server to facilitate the communication between a software application and a smart telemetry device, the method comprising: accepting a request from the smart telemetry device to send information to the application via a protocol native to the smart telemetry device; and forwarding the information to the application via a Web Service technology.
 38. The method of claim 37, wherein the Web Service technology comprises one or more of XML, SOAP, WSDL, UDDI, HTTP, and SMTP.
 39. The system of claim 37, wherein the smart telemetry device comprises one or more of a controller device and a monitor device.
 40. A method used by a server to facilitate the communication between a software application and a smart telemetry device, the method comprising: accepting a request from the smart telemetry device to send information to the application via a first Web Service technology; and forwarding the information to the application via a second Web Service technology.
 41. The method of claim 40, wherein the first Web Service technology comprises one or more of XML, SOAP, WSDL, UDDI, HTTP, and SMTP.
 42. The method of claim 40, wherein the second Web Service technology comprises one or more of XML, SOAP, WSDL, UDDI, HTTP, and SMTP.
 43. The system of claim 40, wherein the smart telemetry device comprises one or more of a controller device and a monitor device. 